EC2 インスタンスへ SSM 接続を行うときの権限について検証してみた

EC2 インスタンスへ SSM 接続を行うときの権限について検証してみた

Clock Icon2024.07.24

こんにちは、森田です。

EC2インスタンスへの SSM 接続制限を考える機会があったので、そのタイミングでSSM 接続に必要な権限を調査してみました。

さきにまとめ

SSM 接続へ明示的に許可する場合

接続先のEC2インスタンスSSM-SessionManagerRunShell ドキュメント へのAllow

ポリシー
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnableSSMSession",
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:instance/*",
                "arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
            ]
        }
    ]
}

SSM 接続へ明示的に拒否する場合

SSM-SessionManagerRunShell ドキュメントをDeny

ポリシー
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DisableSSMSession",
            "Effect": "Deny",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
            ]
        }
    ]
}

SSM 接続について

AWS Systems Manager の機能であるセッションマネージャーを使った接続方法で鍵認証の設定無しで IAM を使って EC2 インスタンスへアクセスすることが可能となります。

利用するための準備がいくつかありますが、比較的簡単に利用開始できます。
詳しくは以下をご参照ください。

https://dev.classmethod.jp/articles/ec2-access-with-session-manager/

SSM 接続を明示的に許可する場合

SSM接続の権限が与えられていない IAM ロールへ明示的にSSM接続の許可を与えるようなケースを想定しています。

付与するポリシー

以下のAWSドキュメントでは、

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/getting-started-restrict-access-quickstart.html

条件要素 ssm:SessionDocumentAccessCheck を true として指定した場合、
セッションの確立前に、ユーザーが定義済みのセッションドキュメントへのアクセスを明示的に許可されていることがチェックされます

と記載されているため、ssm:SessionDocumentAccessCheckがなければ、ドキュメントへの明示的な許可は不要であると考えました。

しかし、実際に以下のポリシーでは SSM 接続はできませんでした。

SSM 接続不可
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnableSSMSession",
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:instance/*"
            ]
        }
    ]
}

ssm:SessionDocumentAccessCheck の有無に関わらず、ドキュメントへの許可は必要です。

SSM 接続可能
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnableSSMSession",
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:instance/*",
                "arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
            ]
        }
    ]
}

明示的に SSM 接続の制限

例えば、AdministratorAccess を持っているロールでは、すべての権限がAllowとなっているため、SSM 接続も可能な状態となっています。

このようなロールに対して、SSM 接続のみ(他のアクセス権限はそのまま)に制限かけたいケースを想定しています。

このようなケースでは、明示的に SSM 接続を拒否するポリシーが必要となります。

付与するポリシー

AWSドキュメントを確認すると、SSM接続を行う際には、SSM-SessionManagerRunShell を自動的に呼び出すとの記載があります。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/getting-started-specify-session-document.html

そのため、SSM-SessionManagerRunShell に対してDenyを行うと制限をかけることができます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DisableSSMSession",
            "Effect": "Deny",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
            ]
        }
    ]
}

迷った点

ssm:SessionDocumentAccessCheckの指定が必要であるかについて少し迷いましたので、実際に試してみました。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/getting-started-specify-session-document.html

ssm:SessionDocumentAccessCheckの指定を行った以下のポリシーでもSSM接続の制限をかけることができましたが、ssm:SessionDocumentAccessCheck の有無で挙動が変わるわけではないので、外しておいた方が無難だと思いました。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "DisableSSMSession",
			"Effect": "Deny",
			"Action": [
				"ssm:StartSession"
			],
			"Resource": [
				"arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
			],
			"Condition": {
				"BoolIfExists": {
					"ssm:SessionDocumentAccessCheck": "true"
				}
			}
		}
	]
}

さいごに

Systems Manager に対して全権限を持たせるケースが多く、あまり権限を意識したことがなかったので、調査することで勉強になりました。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.